Fixes the upstream report mendixlabs/mxcli#772.

Problem

Mendix stores sibling predicate groups concatenated in a single XPathConstraint field:

[Reminders.Task_TaskGroup/Reminders.TaskGroup[EndDate = $EndDateLimit]]
[Status != 'Completed']
[CompletionDate = empty]

describe rendered only the first:

where Reminders.Task_TaskGroup/Reminders.TaskGroup[EndDate = $EndDateLimit];

The reporter's framing is the important part: this is worse than a crash. The output looks complete while describing a materially less restrictive query than the project contains — so correct defensive code reads as buggy, and describe is exactly what an agent reads to decide whether code is right.

Root cause

The grammar's xpathConstraint rule matches one bracket group. ParseXPathConstraint removes the error listeners, so ANTLR parsed the first group, left the rest on the token stream, and still returned ok = true. enrichXPathConstraintForDescribe treated that as a full parse and re-rendered only what came back — its if !ok { return original } fallback never fired.

Confirmed directly before touching anything:

parse ok    = true
re-rendered = "[Reminders.Task_TaskGroup/Reminders.TaskGroup[EndDate = $EndDateLimit]]"

Approach — two layers

1. ParseXPathConstraint rejects a partial parse (require the token stream at EOF). This alone stops the data loss: the caller falls back to the stored string, which the render path then splits correctly.
2. visitor.SplitXPathPredicateGroups splits a constraint into top-level groups, each enriched and rendered separately — so enum enrichment reaches groups after the first, not just the first.

The splitter tracks nesting depth and quoting, because the previous "][" split mangles both a nested [A/B[x = 1]] and a literal containing ] ([Name = 'a]b']). Both appear in real projects, and mishandling either silently changes what a query means. The render path now uses the same splitter instead of its own ad-hoc version.

A group that does not parse is passed through verbatim rather than dropped or guessed at.

Verification

End-to-end on a real 11.12.2 project carrying the reported constraint shape:

• The describe output re-parses and re-executes to an identical flow (full round-trip).
• mxcli docker check → 0 errors.
• Full ./... suite green.

All three guards mutation-checked. Worth noting what that revealed: reverting the per-group split alone does not reproduce the data loss any more, because the strict parse already prevents it — it only degrades enum enrichment ('Completed' instead of the qualified value). That is defence in depth working as intended, and it is why there is a separate enrichXPathGroups unit test rather than relying on the end-to-end one.

Generalisable lesson (recorded in the symptom table)

A parser that silently accepts a prefix is worse than one that fails. Any ok returned by a rule that can match less than its input must be checked against EOF before a caller treats the result as lossless.

Repro script: mdl-examples/bug-tests/772-xpath-constraint-groups.mdl.

Generated by Claude Code